Skip to content

Conversation

@xedin
Copy link
Contributor

@xedin xedin commented Jul 27, 2025

…y and dictionary

The original comment that these overloads can be removed was incorrect because the existential of PropertyListItemConvertible doesn't self conform. The overloads are still needed to support collections with heterogeneous values but nothing else and so they should be disfavored.

Turns out that some of the expressions that used to take advantage of these overloads only work due to the solver producing a valid solution from the "diagnostic" mode.

For example:

public var propertyListItem: PropertyListItem {
    return .init(entries
        .sorted { $0.identifier < $1.identifier }
        .map {
            [
                "bundle-id": .plString($0.identifier),
                "tags": PropertyListItem($0.tags.sorted()),
                "bundle-path": .plString($0.path.str),
            ]
        })
}

This expression should have been ambiguous because it can match both .init(any ...) and .init([any ...]) overloads due to an existential conversion that is bi-directional for the closure.

For .init(any ...), result of the closure is going to be erased to existential inside of the body of the .map closure and for .init([any ...]), this erasure is going to happen outside but both are equally valid.

@xedin
Copy link
Contributor Author

xedin commented Jul 27, 2025

@swift-ci please test

@xedin xedin changed the title [SWUtil] PropertyList: Clarify use of init overloads that take arra… [SWUtil] PropertyListItem: Clarify use of init overloads that take arra… Jul 27, 2025
…array and dictionary

The original comment that these overloads can be removed was incorrect
because the existential of `PropertyListItemConvertible` doesn't self
conform. The overloads are still needed to support collections with
heterogeneous values but nothing else and so they should be disfavored.

Turns out that some of the expressions that used to take advantage
of these overloads only work due to the solver producing a valid
solution from the "diagnostic" mode.

For example:

```
public var propertyListItem: PropertyListItem {
    return .init(entries
        .sorted { $0.identifier < $1.identifier }
        .map {
            [
                "bundle-id": .plString($0.identifier),
                "tags": PropertyListItem($0.tags.sorted()),
                "bundle-path": .plString($0.path.str),
            ]
        })
}
```

This expression should have been ambiguous because it can match
both `.init(any ...)` and `.init([any ...])` overloads due to an
existential conversion that is bi-directional for the closure.

For `.init(any ...)`, result of the closure is going to be erased
to existential inside of the body of the `.map` closure and for
`.init([any ...])`, this erasure is going to happen outside but
both are equally valid.
@xedin xedin force-pushed the address-property-list-ambiguity branch from 6150fe3 to 28d59ad Compare July 27, 2025 07:19
@xedin
Copy link
Contributor Author

xedin commented Jul 27, 2025

@swift-ci please test

@xedin
Copy link
Contributor Author

xedin commented Jul 27, 2025

@swift-ci please test Linux

@xedin
Copy link
Contributor Author

xedin commented Jul 28, 2025

@swift-ci please test Linux

@jakepetroules
Copy link
Collaborator

The Linux job is broken; you need to wait until #673 is merged to unblock the CI.

@xedin
Copy link
Contributor Author

xedin commented Jul 28, 2025

Sounds good, there is no rush with this.

@jakepetroules
Copy link
Collaborator

@swift-ci please test Linux

@jakepetroules jakepetroules merged commit b79d617 into swiftlang:main Jul 28, 2025
41 of 45 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants